home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 15918 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.3 KB
  1. Path: munta.cs.mu.OZ.AU!fjh
  2. From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 8 Apr 1996 20:11:16 GMT
  6. Organization: Comp Sci, University of Melbourne
  7. Message-ID: <4kbrt5$k3h@mulga.cs.mu.OZ.AU>
  8. References: <JSA.96Feb16135027@organon.com> <dewar.828879781@schonberg> <4k9qhe$65r@solutions.solon.com> <dewar.828936837@schonberg> <4kb2j8$an0@solutions.solon.com>
  9. NNTP-Posting-Host: munta.cs.mu.oz.au
  10.  
  11. seebs@solutions.solon.com (Peter Seebach) writes:
  12.  
  13. >Robert Dewar <dewar@cs.nyu.edu> wrote:
  14. >>THe original issue was the semantic behavior
  15. >>of read. Unlike other unices, in Linux, the bounds check for the read
  16. >>buffer is based on the requested count, rather than the actual count
  17. >>of data bytes read. It is hard to say either approach is right or
  18. >>wrong, but they are different enough to cause portability problems.
  19. >
  20. >How?  No offense meant, but any code which can be affected by this is flat
  21. >out broken.
  22.  
  23. It is clear that (a) such code is broken and (b) the fact that
  24. it has undefined behaviour causes portability problems.
  25. What you said and what Robert Dewar said are not contradictory.
  26.  
  27. >I can't see how this is a "portability problem" any more than it's a
  28. >portability problem that some systems will crash on
  29. >    printf("%s", (char *) 0);
  30. >... (SunOS won't, though.) 
  31.  
  32. It is not *more* of a portability problem than `printf("%s", (char *) 0);',
  33. but the undefined behaviour of read() and printf() both cause portability
  34. problems.
  35.  
  36. >Something which works only on some systems is
  37. >not a portability problem *if there is no standard saying it works*.  Likewise
  38. >    i = ++i;
  39. >producing different results on different machines is not a "portability
  40. >problem".
  41.  
  42. Ha!  Obviously you have never tried porting any serious C programs.
  43.  
  44. >(This applies to most of the C standard library, as well, of course.  The
  45. >behavior you're used to, such as "void main(void)" or "fflush(stdin)" not
  46. >working, is not a portability problem, it's broken code.)
  47.  
  48. It's a portability problem AND it's broken code.
  49.  
  50. --
  51. Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
  52. WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
  53. PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
  54.